Object Permissions
Description
Topics include: enabling object permissions, setting object permissions, setting permissions to all objects of a type, where view records permission is required for the underlying table or set, group permission flowchart.
Enabling Object Permissions
Create a password for your database.
Make sure each user has their own account.
Create at least one group.
Add users and assign them to groups.
Setting Object Permissions
You can give various levels of access permissions to use tables, forms, browses, reports, letters, labels, and operations to groups. Tables have a broad set of permissions. All other objects have a limited set of permissions. This screen shows the permissions for a table for a group. Note that for each permission you have three choices: Grant, Deny, and do nothing. "Delete" refers to deleting a table and its indexes. "Design" means restructuring a table, editing its indexes, and changing its field rules.
All other objects have only Delete, Design, and Run permissions. Picture
Granting Permissions to an Object to a Group
To grant permission to an objects to a group:
Select the object (table, form, etc.) in the Control Panel.
Right click and select Set Security.
Click Add to display the Select Groups dialog box.
Place check marks next to the groups you want to add and click OK.
Place check marks under the Grant or Deny columns for each type of permission.
Click OK to apply your changes or Cancel to discard them.
Setting Permissions to All Objects of a Type
To grant permissions to all objects of a type to a group:
Right click on the white space of a Control Panel tab or click Table > Set Security (or Layout > Set Security ) to display the permissions tab for all objects of that type.
Click Add to display the Select Groups dialog box.
Place check marks next to the groups you want to add and click OK.
Place check marks under the Grant or Deny columns for each type of permission.
Click OK to apply your changes or Cancel to discard them.
Where View Records Permission is Required for the Underlying Table or Set
Object security works on an inheritance model. For a layout to be accessible, appropriate permissions must be set for the underlying table/set. For example, in order to run the AlphaSports Customer Information form, a user must also have permission to view records for the underlying table, Customer.DBF. The following permissions require the View Records permission to be set on the underlying table/set.
- Class
- Permission
- Form
Run
- Report
Run
- Browse
Run
- Append Records
Run
- Crosstab
Run
- Copy Records
Run
- Export Records
Run
- Join Records
Run
- Label
Run
- Letter
Run
- Mark Records
Run
- Post Records
Run
- Query
Run
- Summarize Records
Run
- Update Records
Run
- Table
Default Form
- Table
Default Browse
- Set
Default Form
- Set
Default Browse
Group Permission Flowchart
If a group has permission to an object, it must also have permission to dependent objects. For example, "Form:Run" access requires "Table:View" access.
See Also